"Christopher James Huff" <chr### [at] maccom> wrote:
> > No ... this is not what I meant ... I mean, that the prog, can modify itself
> > in memory, to speedup execution ...
>
> Well, what's stopping you? You would have to interface through the
> ordinary POV-Script and write it to the disk in order to load it again,
> but the result would be the same: dynamically generated code being
> loaded into memory and executed. Just a bit roundabout, and a large
> chunk of the required code would have to be written in POV-Script
> instead of being done by the function engine. It would also be very
> slow...

nope... that's not what I meant...
Consider this pseudo-code

-----------------------------------
A=SomeExpression(Input)

repeat

DoSomething()

if (A=SomeValue)
    FarCall SubRoutine1
  else
    NearCall SubRoutine2
endif

DoSomethingElse()

until (End)
------------------------------------

as you can see: the if-instruction is executed very often...
In Self-modifying-ASM-code one could write:

------------------------------------
A=SomeExpression(Input)

if (A=SomeValue)
    [ChangeHere]=OpCodeOf(FarCall SubRoutine1)
  else
    [ChangeHere]=OpCodeOf(NearCall SubRoutine2)
endif

repeat

DoSomething()

:ChangeHere
noop
noop
noop
noop

DoSomethingElse()

until (End)
------------------------------------

I once had a chance, to speed up the Bresenham by a factor of 3 by a similar method.
The thing is that you can decide at runtime, which opcodes get executed, depending
on some runtime values
As there are(were) different opcodes used for a near-jump (target-address, beein in
the same codesegment) and a far-jump (jump to anywhere in memory) there was no easy
chance, to work only with pointers, and only change these...

Of course, my last lines applied to my active assembler time, when  I did some
x86-Realmode ASM ....

I hope you got the idea ...

Post a reply to this message